点击上方 "程序员小乐"关注, 星标或置顶一起成长
每天凌晨00点00分, 第一时间与你相约
每日英文
Someday, you will find the one, who will watch every sunrise with you until the sunset of your life.
总有一天,你会遇上那个人,陪你看每一次日出,直到你的人生落幕。
每日掏心话
每个人的心里,都有一个禁地,不愿再触及,也不愿再想起,却永远无法忘记。既然忘不了,就不必费神忘记,做人本就很累,何必再自寻烦恼。
来自:一点一滴的Beer | 责编:乐乐
链接:/cnblogs.com/beer/p/6029861.html
往日回顾:手把手教你如何解决代码中 if…else 过多的问题
正文
不同的客户端产生了不同的用户使用场景,这些场景:
不同级别的接口调用方式
下面是一些在IT服务常见的一些使用场景:
用户在web浏览器端登录系统,使用系统服务
用户在手机端(Android/iOS)登录系统,使用系统服务
用户使用开放接口登录系统,调用系统服务
用户在PC处理登录状态时通过手机扫码授权手机登录(使用得比较少)
用户在手机处理登录状态进通过手机扫码授权PC进行登录(比较常见)
1. 原始账号密码类别
用户名和密码
API应用ID/KEY
浏览器端token
移动端token
API应用token
3. 接口调用类别
接口访问token
4. 身份授权类别
PC和移动端相互授权的token
1. 使用成本
本认证方式在使用的时候,造成的不便性。比如:
二维码需要用户掏出手机进行扫码操作
本认证方式,token发生变化时,用户需要做出的相应更改的成本:
用户名和密码发生变化时,用户需要额外记忆和重新键入新密码
API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署
授权二维码发生变化时,需要用户重新打开手机应用进行扫码
被偷窥的风险
被抓包的风险
被伪造的风险
1. 使用频率
在网路中传送的频率
2. 有效时间
此token从创建到终结的生存时间
安全和隐私性主要体现在:
token 不容易被窃取和盗用(通过对传送频率控制)
token 即使被窃取,产生的影响也是可控的(通过对有效时间控制)
关于隐私及隐私破坏后的后果,有如下的基本结论:
曝光频率高的容易被截获
生存周期长的在被截获后产生的影响更严重和深远
曝光频率高的token的生存周期要尽量短
将各类token的固有特点及可控属性进行调控后, 对每个指标进行量化评分(1~5分),我们可以得到如下的对比表:
user_name/passwd 和 app_id/app_key 是等价的效果
1. 密码层
2. 会话层
3. 调用层
4. 应用层
用户输入用户名和用户口令进行一次性认证
在 不同 的终端里面生成拥有 不同 生命周期的会话token
客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token
会话token可以生成和刷新延长 access_token 的生存时间
access_token可以生成生存周期最短的用于授权的二维码的token
良好的层次性。
不同平台的可以有完全不同的用户权限控制系统,这个控制可以在 会话层 中各平台解决掉
广义的 账号/密码 有如下的呈现方式:
传统的注册用户名和密码
应用程序的app_id/app_key
它们的特点如下:
比如:用户自己为了方便记忆,会设置有一定含义的账号和密码。
账号密码对用户有特别含义,一般没有特殊情况不会愿意修改。 而app_id/app_key则会写在应用程序中,修改会意味着重新发布上线的成本
3. 一旦泄露影响深远
正因为不常修改,只要泄露了基本相当于用户的网络身份被泄露,而且只要没被察觉这种身份盗用就会一直存在
使用步骤:
用户使用账号密码,换取会话token
主要原因:
1. 环境安全性
2. 输入便捷性
使用具有较长生命周期的会话token来换取此接口访问token。
主要步骤如下:
PC上用户已经完成认证,登录了系统
PC端生成一组和此用户相关联的pam_token
PC端将此pam_token的使用链接生成二维码
移动端扫码后,请求服务器,并和用户信息关联
移动端获取refresh_token(长时效的会话)
根据 refresh_token 获取 access_token
完成正常的接口调用工作
备注:
生存周期为2分钟,2分钟后过期删除
没有被使用时,每1分钟变一次
被使用后,立刻删除掉
此种认证模式一般不会被使用到
主要步骤:
后续正常的调用接口调用工作
被使用后,立刻删除掉
本文所设计的基于token的身份认证系统,主要解决了如下的问题:
token的分类问题
token的隐私性参数设置问题
token的使用场景问题
不同生命周期的token分层转化关系
本文中提到的设计方法,在 应用层 中可以适用于且不限于如下场景中:
用户登录
有时效的优惠券发放
有时效的邀请码发放
有时效的二维码授权
具有时效 手机/邮件 验证码
多个不同平台调用同一套API接口
多个平台使用同一个身份认证中心
欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,学习能力的提升上有新的认识,欢迎转发分享给更多人。
欢迎各位读者加入订阅号程序员小乐技术群,在后台回复“加群”或者“学习”即可。
猜你还想看
阿里、腾讯、百度、华为、京东最新面试题汇集
从上帝视角看Java如何运行
一次项目代码重构:使用Spring容器干掉条件判断
IDEA-2020.1 版本针对调试器和代码分析器的改进,值得期待
文章有问题?点此查看未经处理的缓存